Conventionally, when hardware (sequential circuit) that implements a desired function is designed, logic verification to check for omissions in the design is a fundamental process before moving to manufacture of actual hardware. Specifically, a verification scenario that suits the contents of the hardware design is created, and logic verification is performed using an output result obtained when the verification scenario is input.
Furthermore, verification coverage is obtained to objectively evaluate the verification that has been performed using the verification scenario created as described above. Verification coverage is information concerning an index that indicates the sufficiency of simulation patterns for a subject of verification. Specifically, if the population is all simulation patterns requiring verification, coverage obtained from a rate of the executed simulation patterns is provided as the verification coverage. In this case, verification accuracy is determined to be high if the verification coverage is high.
A problem with this technique concerns the method of extracting “all simulation patterns requiring verification”, i.e., the population. Simulation patterns corresponding to the population are referred to as coverage standards. If patterns are extracted that are not effective practically for verification as coverage standards, the patterns do not necessarily contribute to improvement of actual verification efficiency even if the coverage of the simulation is high.
Therefore, methods called path coverage and code coverage in which patterns are comprehensively extracted according to specific standards are used nowadays. In path coverage, patterns to verify all paths causing state transitions in the register of a circuit under verification are extracted. Therefore, with the path coverage method, these patterns are the coverage standards. Code coverage is also called line coverage, and patterns are extracted to verify paths related to input and output of the register in which source codes corresponding to a circuit under verification are described. Further, in the code coverage, these patterns are the coverage standards. Such techniques are disclosed in, for example, Japanese Laid-Open Patent Publication Nos. 2006-190209 and 2006-201980, and “Assertion-Based Design” (2nd Edition) by Foster, Harry D., et al., “Programming Code metrics”, pp. 129-130, 2004.
However, even if a verification scenario comprehensive of the coverage standards as described above is created and verification is performed using the verification scenario, a bug due to an omission of verification may occur when the sequential circuit is actually operated, even if the coverage standards described above are 100 in the verification scenario; a consequence originating in a verification oversight of timing constraints that are given as a hardware specification corresponding to register transistor logic (RTL) description.
FIG. 22 is a schematic diagram for explaining input/output information of a hardware unit. As depicted in FIG. 22, to a hardware unit 2200, a request (req) 2201, a condition A 2202, and a condition B 2203 are input as input information. Furthermore, data 2204 that indicates a result of processing by the hardware unit 2200 and an acknowledgement (ack) signal 2205 giving notification that data has been output normally from the hardware unit 2200 are output as output information. Moreover, as described above, the hardware unit 2200 is a sequential circuit. Therefore, as hardware specifications, constraints related to timing are included in addition to constraints related to the input/output information, as described above.
FIG. 23 is a chart of one example of hardware specifications. A chart 2300 indicates specifications for the hardware unit 2200. As depicted in the chart 2300, one specification is for the data 2204 corresponding to the condition A 2202 and the condition B 2203, which are input to the hardware unit 2200, to be output within five cycles, when the request 2201 is input (“1”). When the data 2204 is output from the hardware unit 2200, the ack signal 2205 giving notification of the output of the data 2204 is output. If the request 2201 is not input (“0”), neither the data 2204 nor the ack signal 2205 are output, and therefore, the condition A 2202 and the condition B 2203 do not affect the output regardless of values thereof (d.c: don't care).
FIG. 24 is a timing chart of an example of operation corresponding to the specifications of the hardware. When the request 2201 has been input (“high state”) to the hardware unit 2200, according to the hardware description, determination of the condition A 2202 is started at the first clock start timing C0. After a predetermined number of cycles (in this example, it is assumed that the determination of the condition A 2202 takes one cycle), determination of the condition B 2203 is started at a following clock start timing C1. When the determination of the condition B 2203 is completed after a predetermined number of cycles (in this example, it is assumed that the determination of the condition B 2203 takes four cycles), the ack signal 2205 is output. Upon output of the data 2204 corresponding to this ack signal 2205, the input of the request 2201 is ended (“low state”). In the example depicted in FIG. 24, it takes five cycles from the input of the request 2201 to the output of the data 2204, thereby satisfying the timing specifications.
With the conventional verification coverage, in the path coverage standards, a verification scenario is created for each path corresponding to conditional branching for hardware that is designed based on the specifications as described above, thereby improving the verification accuracy. FIG. 25 is a chart of coverage of each verification scenario. FIG. 26 is a schematic diagram for explaining one example of a control flow graph (CFG) expressing a circuit to be verified. If a circuit to be verified is expressed as CFG 2600 depicted in FIG. 26, normally, a verification scenario as depicted in a chart 2500 is created. Numerals in blocks of the CFG 2600 indicate the number of cycles required for processing.
When a verification scenario 2510 of items b, c, and d is executed, all paths are covered as expressed by broken lines in FIG. 26. Therefore, even when a verification scenario 2520 of an item a is not used, or the verification scenario 2520 of the item a is not created, the path coverage standards have the coverage of 100.
If there is no error in the hardware description, it is possible to find a bug without omission by performing verification that satisfies the coverage standards as described above. However, when there is an error in the hardware description, oversight in verification can be caused when the specification is not satisfied, or the like.
A case where verification oversight is caused concerning a conditional branch is explained. FIG. 27 is a schematic diagram for explaining an example in which an error in a conditional branch is overlooked. For example, when a sequential circuit is designed that outputs a result of determination of the condition A 2202 and the condition B 2203 within five cycles according to a timing specification, correct description (CFG 2600) conforming to the timing specification may be changed to an incorrect description (CFG 2700) such as when a designer makes an error when attempting to make a correction.
FIG. 28 is a chart of the number of cycles corresponding to a conditional branch. As depicted in a chart 2800, according to an example of correct description, the data 2204 is output within five cycles through any conditional branch path. On the other hand, in an example of incorrect description, although the data 2204 can be output in the verification scenario 2810 for the items b, c, and d according to the specifications, it takes six cycles to output the data 2204 in the verification scenario 2820 for the item a. As a result, in the example of incorrect description, a bug occurs when both the conditions A and B are “1” (path 2701 depicted in FIG. 27). In other words, although the verification scenario 2820 of the item a is an effective verification scenario to detect a bug, there is a high possibility that the verification scenario 2820 of the item a is not created in the conventional coverage standards described above.
Moreover, when the line coverage described above is used as the coverage standards, verification of paths corresponding to the description of source code corresponding to a sequential circuit to be verified is a problem either in correct description or in incorrect description. Therefore, if the verification scenario 2810 of the items b, c, and d are created, the coverage becomes 100 coverage.
As described, in the conventional coverage standards, coverage concerning the conditional branch in a circuit to be verified may not be completely covered even if a verification scenario that achieves 100 coverage is created.
However, a technique to confirm coverage of conditional branches by a created verification scenario has not been provided. Therefore, incorrect description cannot be extracted as a problem when hardware description has been changed to incorrect description as explained with reference to FIG. 27, and there has been a problem that hardware design inclusive of a bug is provided.